The staging e2e "generic" leg was red on ~100% of runs because a few
independent failures sat behind an all-or-nothing gate:

- whatsapp-phone-code: the WhatsApp channel is not enabled on the staging
  instance, so the button never renders and the suite times out every run.
  It also bypasses the isStagingReady graceful-skip, so skip it explicitly
  on staging until the channel is provisioned.
- custom-pages "survives a parent rerender": validates an unreleased
  @clerk/react fix (#8604), but the staging leg installs published @latest,
  so it is deterministically red until release. Skip when E2E_SDK_SOURCE=latest;
  PR CI (ref builds) still covers it.
- concurrency was keyed on ref (effectively always "main") with
  cancel-in-progress, so each new staging deploy cancelled the in-flight run
  and no commit could report a status. Key on the clerk_go commit instead.
- raise the job timeout above the 25-minute test step so the job cap no
  longer kills runs mid-suite.
- emit and upload a JSON Playwright report in CI so the report job can
  classify failures (flaky vs failed, infra vs regression) later.

…nformational

The generic leg runs ~210 tests against one shared staging instance, so any
single post-retry flake reds the whole matrix and the staging run has been ~100%
red, giving no signal. Split the gate: tag a handful of stable core-auth happy
paths @smoke and run them as their own small matrix leg against just the two
core apps, and mark the full generic leg continue-on-error so it still runs and
uploads results but no longer fails the run.

Because only gating legs (smoke + the framework legs) can fail the matrix job,
needs.integration-tests.result is 'failure' only on a real gating-leg failure,
so the report job's Slack notification fires on meaningful failures instead of
on generic-only flake.

The initial @smoke set is intentionally conservative (sign-in with password /
instant password / modal, sign-up with password, sign-out) and is just tags, so
it can grow as flake is brought under control.